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ABSTRACT 



This thesis investigates the issues of validation and 
verification of the Communications Load Model (CLM) being 
used in the Battle Group Communications Simulation Facility 
at the Naval Air Development Center. The processes involved 
in creating user input files are explained and evaluated. A 
user’s guide is included to assist the user in interpreting 
input into the proper data structure and format for use by 
the model. Structure and function of the model and its 
components are examined. Calculations of results predicted 
by scenario inputs are compared to actual program output. 
The analysis is used to determine appropriate methodology to 
be utilized in validation and verification of the CLM. 
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I. INTRODUCTION 



The ever increasing complexity of the modern tactical 
battlefield environment poses many problems to the armed 
forces of the United States and its allies. In order to 
mount a campaign with any chance for success the sustained 
operation of communication, command and control (C^) links 
between all of the deployed forces is required. Not only 
must such a linking network be sustainable in the midst of a 
hostile electronic environment, it must be secure and free 
from interception and intrusion. Design, testing and 
implementation of a network system meeting these 
requirements can be a long and costly process. 

The need for a system simulation model to serve as a 
test bed for evaluation of proposed network designs led to 
the development of the Communications Load Model (CLM). Use 
of such a model for design specification evaluation offers a 
means of reducing the risk of funding full-scale development 
of tactical communication systems. This thesis examines the 
potential usefulness of the CLM as a development tool and 
investigates the approach to validation and verification of 
the CLM. 

Originally developed to support Air Force efforts on the 
Joint Tactical Information Distribution System (JTIDS), the 
CLM is now undergoing further development at the Naval Air 
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Development Center (NADC) for use in the Navy’s current 
JTIDS project. The CLM has been extensively modified from 
its original configuration in order to accommodate a wider 
variety of communication network specifications. 

The CLM is actually a system made up of separate 
programs that together perform a complex set of functions. 
User developed input data files supply descriptions of force 
units, capabilities, and instructions for force group 
campaign activities. The CLM performs a wargame simulation 
based on the input data and produces a chronologically 
tagged file of action states resulting from the outcome of 
the campaign events. These action states are used to 
trigger message events as defined by communication doctrine 
specified by user input. The resulting message load is 
applied to the Communication System Model where the impact 
of the load may be evaluated for different network design 
specif i cat ions . 

Major functions of the CLM include kinematics, 
detection, response, attrition, and communication. The 
first four functions named are involved in the events of the 
wargame simulation. The communication function is handled 
by the Communication System Model, receiving the action 
state information output from the wargame simulation. 

With the planned configuration of the CLM still under 
development, NADC, in seeking support for this development 
effort, has offered to sponsor thesis research work at the 
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Naval Postgraduate School (NPS). In a memo dated 22 OCT 
1986, by LCDR Neal Hesser, director of the Information 
Transfer Systems Program at NADC, *'Verif ication of the 
Communication Load Model" is proposed as a topic for thesis 
research. As stated in the memo, "areas for thesis work 
include scenario development and validation, mission 
directive verification and validation, message coupling 
verification, and force group action simulation verification 
and validation". 

The intent of this thesis is to investigate the 
structure and function of the CLM in order to determine the 
best approach to the validation and verification process and 
lay the groundwork of support for these efforts to be 
undertaken as follow-on thesis projects. A user’s guide for 
creation of input data files is included in this thesis to 
facilitate working with the CLM. 

A scenario was designed during this study to use in 
evaluation of the CLM functions. Data output from running 
the scenario are examined and compared to expected results. 
This analysis is used to illustrate the methods necessary to 
perform validation testing of the CLM functions. 

The organization of this thesis is arranged to give the 
reader a basic familiarization of the CLM and then build on 
that understanding by examination and explanation of the 
components of the model and how they function. Chapter II 
contains background information on the CLM and describes its 
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overall structure and organization. Chapter III describes 
the methodology employed in carrying out the different 
phases of this project. Chapter IV contains descriptions of 
the input data sets used for the scenario and gives an 
analysis of expected versus actual results from the 
scenario. Chapter V addresses the issues of validation and 
verification of the CLM functions. Chapter VI offers 
conclusions and recommendations. Appendix A contains a 
user’s guide to facilitate the creation of user input data 
files. Appendix B contains the CLM input and output data 
files . 
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II. THE COMMUNICATIONS LOAD MODEL 



The purpose of the CLM is to convert a tactical military 
scenario into realistic communication traffic loads for the 
evaluation of network management schemes. While the CLM was 
originally intended for application to the development of 
the Joint Tactical Information Distribution System (JTIDS), 
continued development and modification are intended to make 
the CLM suitable for application to the general tactical 
communication network problem. 

A. CLM BACKGROUND 

The Communications Load Model (CLM) is a set of computer 
programs originally developed for the Joint Project Office 
(JPO) at Hanscom Air Force Base, MA. The CLM development by 
MAR, Incorporated of Rockville, MD , under contract to the 
JPO, was begun in October, 1979. The Development of two 
ancillary programs, the Events Simulation Module (ESM) and 
the Link Evaluation Simulator (LES) were subcontracted to 
Network Analysis Corporation, a subsidiary of ConTel.. 

The initial development phase continued until 1982. It 
was in 1982 that the Naval Air Development Center received a 
set of CLM programs from the JPO at Hanscom AFB. The CLM 
had not, at that time been tested or verified. It was not 
delivered as a finished product, and the programs comprising 
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the CLM were not integrated into a single working system. 
It had not, to that date, been utilized for any specific 
purpose in conjunction with JTIDS or any other system. 

In conjunction with the initial efforts to utilize the 
CLM at NADC , a contract was made with MAR, Incorporated, in 
1982 to provide program documentation for the CLM. The 
primary documents provided under this contract were the 
Communications Load Model (CLM) Computer Program Development 
Specif ication and the User’s Manual For The Communications 
Load Model <^CLM) . ^ 

The first task facing the NADC C^ Lab in its effort was 
the conversion of the programs to a format compatible with 
the VAX/UNIX environment and its particular version of 
FORTRAN 77. The CLM had been developed ' on a Data General 
model S-230 computer, written in FORTRAN V, a much more 
restrictive environment with respect to memory capacity as 
compared to the VAX system in the C^ Lab at NADC. Once the 
conversion was complete in September 1982, the programs, as 
installed on the VAX/UNIX system, and the MAR, Incorporated, 
1982 documentation became what is referred to in this work 
as the baseline version of the CLM. 



^ Background information obtained in interviews with 
Mr. Fred Mill of BDM Corporation, formerly of MAR, 
Incorporated . 
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B. CLM PROGRAM COMPOSITION 



The description of the CLM given here will consist of 
the configuration and function of the baseline version, 
followed by changes that have been implemented and changes 
that are planned. The following description of the baseline 
version is based on information drawn from the program 
specification [Ref. 1] and the user’s manual [Ref. 2]. 

The configuration of the CLM version delivered by MAR in 
1982 is that of a system of six programs and their 
associated input and output files. The six programs that 
comprise the CLM are composed of two hundred twenty-one 
subroutines and more than twenty-one thousand lines of 
FORTRAN code. Listed in order of execution, the six 

programs are: 

1. PREPROCESSOR 

2. PREWAR 

3. WARGAM 

4. PREGEN 

5. CLG 

6. POST PROCESSOR 

A brief description of each program and its associated 
input and output files will be presented here. 

1. PREPROCESSOR 

This program is composed of 46 subroutines with 
7,654 lines of FORTRAN code. The function of PREPROCESSOR 
is to accept user input data files, perform checks, extract 
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data and prepare input data files in an acceptable form for 
the PREWAR and PREGEN programs. 

The user input files, DATBAS, SENSET, and CONDAT are 
checked for correct formats, data types, legal value ranges, 
and completeness. A description of these user input files 
is included in part C of this section. Once the checks have 
been successfully completed, raw data are extracted to 
produce the output files RAWGAM and RAWCLG, which are 
supplied as input files to the PREWAR and PREGEN programs, 
respectively. 

An additional output file, PROUT, is also produced 
as a diagnostic aid. in the event that the PREPROCESSOR 
does not successfully complete its run, an error message 
will be displayed. The file PROUT contains tables that 
indicate in which input file(s) the error(s) occurred and 
displays information on data category, field and type of 
error for each error encountered . ^ PROUT is an extremely 
useful tool for debugging user input files. 

2. PREWAR 

This program is composed of 10 subroutines with 
1,156 lines of FORTRAN code. The function of PREWAR is to 
accept the file RAWGAM from PREPROCESSOR and create all the 
linkages between entities and attributes to be utilized in 
WARGAM. PREWAR produces the output files SMTHGM and MISSDR, 



2 Refer to Table B-5, Appendix B for PROUT example. 
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smoothed wargame inputs and mission directives, 
respectively, in binary readable form for input to the 
program WARGAM. Off-line printout is provided in the file 
PWOUT. 

3. WARGAM 

This program is composed of 96 subroutines with 
8,059 lines of FORTRAN code. The function of WARGAM is to 
accept the files SMTHGM and MISSDR from PREWAR and simulate 
the campaign activities of the scenario by executing the 
mission directives as prescribed by the user input data. 
WARGAM produces the output files ASRCRD, EVENTS, and WGOUT, 
which are the action state records, chronological campaign 
events, and the off-line printout, respectively. 

4; PREGEN 

This program is composed of 8 subroutines with 517 
lines of FORTRAN code. The function of PREGEN is to accept 
the RAWCLG file from PREPROCESSOR, the SMTHGM file from 
PREWAR, and the ASRCRD file from WARGAM, and create all the 
linkages between the entities and attributes to be utilized 
in the communication load generator (CLG) . PREGEN produces 
the output files SORTAS and SMTHLG , sorted action states and 
smoothed message inputs, in binary readable form for input 
to CLG, and the file PGOUT for off-line printout. 

5 . CLG 

This program is composed of 48 subroutines with 
2,916 lines of FORTRAN code. The function of CLG is to 
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accept the files SORTAS and SMTHLG from PREGEN and generate 
a message load in accordance with prescribed communications 
doctrine. CLG produces the message event file, MSGENT, the 
force unit relative position file, URELPS, a file of time- 
tagged group positions and velocities, GRUPOS , and the file 
CGOUT for off-line printout. 

6. POSTPROCESSOR 

This program is composed of 13 subroutines with 815 
lines of FORTRAN code. The function of POSTPROCESSOR is to 
accept as input the f i les ' D ATBAS , SENSET, RAWGAM, SORTAS, 
MSGENT, URELPS, and GRUPOS and produce ESMFIL for use in the 
Event Simulation Model (ESM). The ESM is a time division 
multiple access (TDMA) network simulator developed by ConTel 
to evaluate proposed JTIDS configurations. 

C. CLM INPUT FILES 

Input to the CLM is achieved by way of user created data 
files. The two files which make up the user interface to 
the CLM are DATBAS and SENSET. All of the information 
necessary to construct forces and campaign activities is 
entered in these two input data files. 

In the baseline configuration of the CLM, there is no 
"user friendly" interface mechanism to facilitate the entry 
of user data into the input files. In conjunction with the 
FORTRAN environment of the CLM programs, the input files are 
constrained to the 80 column punch card format. The user 
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must, therefore, have not only a precise knowledge of the 
forces, units, and capabilities to be utilized, but must 
also have a complete understanding of the data structures 
necessary to express that information as input acceptable to 
the programs. A misplaced decimal point or failure to pad 
out a field with blank spaces can have disastrous results. 
A brief description of the input files will be presented 
here . 

1. DATBAS 

This file is designed to be a single resource data 
base for use in all scenarios. User defined forces, unit 
types, and capabilities are entered into DATBAS. As the 
number of entries increases, DATBAS may be used as a catalog 
from which many scenarios may reference any or all of the 
definitions contained therein. 

The basic element employed in the scenario modeled 
by the wargame is the force unit. Capabilities for weapons, 
sensors, communications and jamming are assigned by user 
input to each unit type defined in DATBAS, as are other 
attributes such as unit size, speed, and priority as a 
target. 

Units may be designated as members of force groups. 
Each force group has user assigned attributes such as type 
of group, home base, chain of command, and radius of 
dispersion . 
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Force groups may be designated as members of super 
groups. This arrangement is useful when several force 
groups are deployed in formation. 

For a detailed description of DATBAS structure and 
usage refer to the User’s Guide in Appendix A. 



2. SENSE! 

This file contains the user input parameters that 
describe the campaign activities to take place in an 
individual scenario. A separate SENSE! file must be 
constructed for each scenario. Preplanned campaign 
activities to be carried out by each group in a scenario are 
specified as mission macro instructions and mission 
directives in the user input file SENSE!. In addition to 
the preplanned campaign activities, defensive reaction 
activities are initiated automatically in the program 
WARGAM. Each of these campaign activities results in an 
action state record that is stored in a chronological file. 

For a detailed description of SENSE! structure and 
usage refer to the User’s Guide in Appendix A. 



3. CONDA! 

An additional input file, CONDA!, supplies data for 
program execution control to all of the programs with the 
exception of Postprocessor. The data contained in CONDA! 
directs the flow of input and output files between the 
programs during the sequential execution of the CLM. 
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D. CLM OUTPUT 



The ultimate product of the CLM is a stream of message 
events that are related to the campaign activities of forces 
as modeled in the wargame. The message events are driven by 
communication doctrine as prescribed by the user, and may 
represent the transmission of a single-send message, the 
initiation of a periodic stream of repetitive messages, or 
the termination of a periodic stream of repetitive messages. 

Communication doctrine specified in the user input file 
DATBAS causes specific message types to . be sent by 
designated units as a result of specific action states. 
Thus the combined message traffic of all units participating 
in a given scenario generates the communications load used 
to evaluate system capacity, function, and response. 

E. CLM CHANGES 

The first change to the overall functional design of the 
CLM was made due to the fact that the ESM and LES programs 
had never been properly interfaced to the CLM. As a result, 
there was no attempt to utilize these programs at NADC . 
Since the Postprocessor program of the CLM was designed to 
provide input specifically for the ESM, it was rendered 
essentially useless and omitted from the normal runtime 
configuration of the CLM. 

A much needed improvement to the process of creating 
DATBAS and SENSET files is currently under development. A 
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user interface consisting of two menu-driven editors 
isolates the user from the details of data structures. The 
implementation of this "user friendly” interface will do 
much to facilitate creating and editing the user input 
files. Future plans include the integration of this 
interface into a new preprocessing module to replace the 
existing PREPROCESSOR. 

A new set of programs to provide the postprocessing 
capabilities necessary for network modeling and analysis are 
currently under development by the Lab at NADC. In order 
to provide proper interfacing with the new postprocessing 
facilities, the programs PREGEN and CLG (Communication Load 
Generator) have been replaced by two new programs, PreASG 
and ASG (Action State Generator) respectively. 

The function of PreASG is to accept the output from 
WARGAM, sort the mission events and send the files SORTAS 
and SMTHLG to the program ASG. 

The function of ASG is to expand force group tracks into 
individual platforms thus providing unit resolution, provide 
Killed In Action information on each unit, and provide a 
chronological file of group positions and velocities, 
GRUPOS. Action states, in the file ACTION, and their 
coupled message events, in the file MSGENT, along with 
GRUPOS make up the interface to the new postprocessing 
facilities of the CLM. 
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The changes in the programs have necessitated some 
changes in the input data files DATBAS and SENSET. 
Categories within these files have been added, deleted or 
modified as required to accomodate the program changes. 
These changes are noted in the detailed descriptions of the 
data stuctures in the User’s Guide in Appendix A. Most of 
the data changes are the result of changes in the manner in 
which simulated message traffic generation is handled in the 
programs . 

There is no coherent body of documentation for the 
programs that comprise the postprocessing section of the 
CLM. Information upon which the following descriptions are 
based is drawn from material prepared for briefing 
presentations, informal design notes, and interviews with 
personnel involved in the development effort in the Lab 
at NADC. 

One of the postprocessing programs that is already 
functional is the graphic display package. The program, 
NEWVLT (Video Look-up Table), is written in C programming 
language and includes modules that generate output for 
geographic, message loading, and network capacity displays. 
The output is used to drive a RAMTEK 9460 color graphic 
display system connected by DMA channel to the VAX system. 

The geographic display presents a grid of 20 degrees 
longitude by 15 degrees of latitude upon which force 
dispositions are displayed. Force movements and actions are 
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displayed as the scenario is played according to mission 
macro instructions and mission directives. Sensor 
detections, track reporting, and message traffic between 
units are displayed as color coded vector lines between the 
units involved. 

The message loading and network capacity displays are 
represented as line graphs. Individual lines within the 
graphs are color coded to depict message loads generated by 
specific events or a related set of events. 

Two postprocessing modules that are under development at 
this time are the Communication System Model and the 
Propagation Loss and Jamming Model. These two modules are 
intended to give the CLM the power and flexibility to 
evaluate the performance of a variety of communication 
networks under a wide range of conditions. Of these two 
modules, the Communication System Model is considered to be 
the main component for CLM postprocessing. 

There is a set of utility programs that perform the task 
of conditioning data output from the ASG program of the CLM 
for use as input to the postprocessing programs. 

The Propagation Loss and Jamming Model receives 
information on forces, positions, action states, and message 
events and produces a connectivity matrix. The matrix is 
intended to provide the status of connectivity between units 
expressed as a binary yes/no. Connectivity is based on the 
criteria of 1 ine-of-s ight between units, signal strength. 
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and jamming as determined by the input data. The 
connectivity matrix is provided as input to the 
Communication System Model. 

The Communication System Model receives input from the 
Propagation Loss and Jamming Model, conditioned input from 
the ASG program and direct user inputs concerning Net 
Participating Groups (NPG) and the Capacity Run Limits of 
the network. The output of the Communication System Model 
is the Composite Message/ Analys is file that has been 
tentatively named NETMESS. 

The information input for Net Participating Groups 
includes definitions of group designation, group composition 
by unit type and number, communication capacity by platform, 
and NPG unit designated as Relay. 

It is anticipated that the implementation of the 
postprocessing facilities will provide the CLM with the 
capability to evaluate the impact of multinet and joint 
service operations on network design and unit loading. 
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III. METHODOLOGY 



The aim of this thesis is to examine the approach to 
validation and verification of the Communications Load Model 
(CLM) . Additionally, the potential of the CLM as a 
development tool and training aid in Communication, Command 
and Control systems will be evaluated. 

The CLM is a very large and complex model. The first 
step in approaching the problem of validation and 
verification is to attain a solid understanding of the 
model, its components, and their relationships. The 
methodology for accomplishing this will be described in this 
section. 

Initial study of the CLM began with the receipt of 
program documentation in December, 1986 from LCDR Neal 
Hesser, JTIDS Project Officer at NADC . Documents received 
were the Communications Load Model (CLM) Computer Program 
Development Specification and the User’s Manual for the 
Communications Load Model (CLM). As a result of telephone 
discussions in December, 1986 and January, 1987 with LCDR 
Hesser and Mr. Wayne Phillips, CLM project engineer in the 
C^ Lab at NADC, a determination was made to install the CLM 
at the Naval Postgraduate School (NPS). Installation was to 
be on the VAX 11/780 computer in the Wargaming Analysis and 
Research Laboratory (WARLAB) at NPS, as the CLM was already 
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running on VAX 11/780 system at NADC. The only difference 
between the two VAX systems is the VAX at NADC uses the UNIX 
operating system, while the VAX at NPS uses the VMS 
operating system. This was not considered to be a major 
obstacle since both operating systems support the FORTRAN 77 
programming language compiler. 

In order to begin familiarization with the CLM and 
prepare for the planned installation at NPS, the author 
travelled to NADC at Warminster, PA from the 4th through the 
6th of February, 1987. During this time, interviews were 
conducted with key personnel involved in the CLM development 
project. Briefings were also given on the structure, 

function, and operation of the CLM by Mr. Wayne Phillips. 
Observations were made of the CLM in operation while running 
the scenario Seawar 85. A complete set of CLM files was 
output to a tape backup unit in VMS format to be transported 
back to NPS. 

Upon return to NPS, the task of installing the CLM on 
the VAX/VMS system in the Wargaming Lab began. The first 
attempt at compiling the FORTRAN source code failed. When > 
the cause of the compile errors was determined, all of the 
program modules were edited accordingly. After the time 
consuming editing process was completed, all of the program 
modules compiled successfully. 

Once compiled, the object modules were arranged into 
program libraries to be linked into executable code. At 
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this point, many errors ocurred in the linking process, 
bringing progress to a halt. In an attempt to overcome 
these obstacles Mr. Wayne Phillips travelled to NPS to 
assist with the installation effort from 22 to 27 April, 
1987. After approximately fifty hours of intense 
troubleshooting effort, very little progress had been made. 
At that point it was determined that installation of the CLM 
on the VAX/VMS system in the NPS Wargaming Lab would not be 
feasible within the time constraints of completing the 
research for this thesis. After careful consideration of 
the alternatives, it was decided that the best way to 
complete the research phase of this thesis effort would be 
to have a dedicated week of working time with the CLM on 
site at NADC. To- accomplish this, the author spent the week 
of 15 through 19 June, 1987 -at NADC. The activities of the 
week-long effort at NADC will be described here. 

The plan of action for the evaluation of the CLM called 
for writing a new and untried scenario, running the 
scenario, and analyzing the performance of the CLM during 
the run and the results of the run. 

The process of writing the scenario was to be evaluated 
and documented for the purpose of producing a user’s guide 
as part of this thesis. The results of running the scenario 
were to be compared to the expected outcome based upon the 
scenario design. This comparison is to serve as the basis 
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for approaching the issues of validation and verification of 
the CLM. 

The first step taken in preparing to construct the 
scenario was to draw up a "game plan” outlining the type of 
events to take place, the number and types of units to be 
involved, and the disposition of the forces on the "playing 
field", which is laid out as a grid of 15 degrees of 
latitude by 20 degrees of longitude. Plotting this area on 
a piece of graph paper makes it much easier to plan mission 
routes and calculate distances and times required to execute 
mission macro instructions and mission directives. An 
example of the grid is shown in Figure 3-1. 

An air strike by Blue forces against a Red Base is the 
scenario . for this study. The Blue forces consist of an 
aircraft carrier and, two air strike groups. Each air strike 
group is made up of four sections (pairs) of strike aircraft 
accompanied by fighters for defensive air cover, with six 
sections in the first group and four sections in the second 
group. The extra fighter sections in the first group are 
intended to absorb the first round of SAMs launched and 
engage the first wave of defensive fighters launched from 
the Red Base. 

An air base and a collocated surface-to-air missile 
(SAM) base comprise the Red forces. Twelve sections of 
defensive fighters are assigned to the Red Base. Twenty 
missiles are assigned to the SAM base. 
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With the scenario plan roughed out, the next step was to 
convert the plan to input for the files DATBAS and SENSET. 
Complete listings of these files with accompanying 
explanations are included in Appendix B. 

After the input files were created, the command "RUNCLM" 
entered at the console set the model in operation. The 
console must be in the directory containing the DATBAS and 
SENSET files that are to be used for the current run. 

When the CLM completes its run, output is available to 
be run through the graphic display facility, providing a 
visual representation of the action states generated by the 
scenario. Elapsed time for the wargame is displayed along 
with the actions of the forces on the grid. This allows for 
initial analysis of the scenario for correctness by visual 
inspection. Detailed analysis of the results of the 
scenario may be accomplished examining the wargame battle 
history in the output file WGOUT. This file contains time, 
position, velocity vectors and event type for all events 
occurring for each force group in the scenario. Selected 
listings of WGOUT are included in Appendix B. 

Analysis and comparison of CLM scenario input with 
scenario output will serve as the basis for addressing the 
approach to issues of validation and verification of the 
CLM. 
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IV. DATA SETS 



The data sets utilized for the construction of the user 
input files DATBAS and SENSET will be discussed in this 
section. The meaning of the data sets will be evaluated in 
terms of expected results in the scenario. 



Output data of the actua 
will also be presented in this 
of the file WGOUT will be 
explained in terms of the 
occurred during the run. A 
WGOUT will not be included, as 
and would add considerably 
without adding commensurately 
issues under consideration her 

A. DATBAS 



1 results of the scenario run 
section. Selected contents 
examined and their meaning 
actual scenario events that 
complete listing of the file 
it is 712 kilobytes in size 
to the heft of this document 
to the illumination of the 



This input data file contains the definitions for all of 
the force units and their capabilities. A summary of the 
forces involved in the Blue air strike vs. Red air base 
scenario is given in Table 4-1. The interpretation of these 
forces and their capabilities as DATBAS entries is presented 
in Table B-2 of Appendix B. 
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TABLE 4-1 



SUMMARY OF FORCE COMPOSITION 
Red Forces 



1. Air base with 150 NM range radar and point 
defense . 



s 

I 



2. 12 sections (total of 24) of defensive air 

fighters with radar and air-to-air weapon 
capabilities . 



3. Long range surface-to-air missile site with 150 NM 
range radar and 20 SAMs with 90 NM maximum range. 
SAM site is collocated with air base. 



Blue Forces 



1. Aircraft carrier with point defense. 



2. E-2 long range surveillance aircraft with 250 NM 
range radar. 

3. 10 sections (total of 20) of defensive air 
fighters with radar and air-to-air weapon 
capabilities . 



4. 8 sections (total of 16) of attack aircraft with 

radar, air-to-surf ace weapon, and air-to-air 
weapon capabilities. 



B. SENSET 

Data defining 
involved in the Blue 
are contained in this 
included in Table B-3 
the scenario events 



the 
air 
file. 

of Appendix 
is presented here. 



by the forces 
Red air base scenario 
listing of SENSET is 
narrative summary of 
Selected data from 



actions to be taken 
strike vs. 

A complete 
B . A 
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the wargame output file WGOUT are presented here for the 
purpose of comparison of actual results of the functioning 
of the CLM programs against the expected outcome based on 
program input. Calculations are based on equations utilized 
by the CLM programs as defined in the program specifications 
[Ref. 1]. 

Initial conditions have the Red Base fixed at position 
(10.00, 12.00) on the grid and the Blue Carrier starting at 
position (10.00, 3.00) on the grid as shown in Figure 4-1. 
All aircraft, both red and blue, are on deck at their base 
and carrier grid positions respectively. 

With the Blue Carrier steaming north at 30 knots, the 
first event upon game initiation is the E-2 proceeding to 
station. Station for the E-2 is a north-south track 50 NM 
in length at 25,000 feet altitude, 240 NM north of the Blue 
Carrier . 

C. COMPARISON OF RESULTS 

Strike groups 1 and 2 must launch from the Blue Carrier 
at such time that foil-owing their respective strike routes, 
they will reach the target. Red Base, at 2.50 and 2.55 hours 
game time respectively, as prescribed by the mission macro 
instructions. Taken from WGOUT, Table B-5 in Appendix B 
shows that Strike Group 1 began its takeoff event at game 
time 0.983, with individual group (section) takeoff events 
from time 0.984 through time 0.990. Strike Group 2 takeoff 
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begins at time 1.033 and is completed at time 1.040, also 
shown in the table. 

Given that the strike routes both begin at position 
(10.00, 3.00) on the grid and run equal distances to the 
target, as shown in Figure 4-2, the start times on the 
strike routes are computed as shown in Table 4-2. Based on 
this calculation, the expected times for Strike Group 1 and 
Strike Group 2 to start on the strike routes are 1.06 hours 
and 1.11 hours respectively. Grid positions used in SENSET 
must be multiplied by 60 in order to be reconciled with 
group positions given in WGOUT . 
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TABLE 4-2 

CALCULATED START TIMES FOR STRIKE ROUTES 

Distance along strike routes : 689.12 NM 
Mission speed of aircraft : 480 NM/H 
Elapsed time on strike routes = 
689.12 NM / 480 NM/Hour = 1.436 Hours 
Game time at target for: 





Strike 


Group 1 


= 2.50 


Hours 






Strike 


Group 2 


= 2.55 


Hours 




Game time 


to start 


on route for: 




Strike 


Group 1 


= 2.50 - 


1.436 


= 1.064 


Hours 


Strike 


Group 2 


= 2.55 - 


1.436 


= 1.114 


Hours 



H 
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Figure 4 - 2 . Blue Air’Strike Routes. 
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As can be seen in comparing the calculated results from 
Table 4-2 with the actual output from WGOUT in Table 4-3, 
the strike route start times are very close. Minor 
differences of 0.018 hour for Strike Group 1 and 0.015 hour 
for Strike Group 2 can possibly be accounted for by the 
following reasons: 

1. The program assigns each member of the group a 
separate takeoff event time. The "launching" 

and coordinating of the strike groups by the 
program is a very complex process. 

2. Each group member is assigned an offset range and 
bearing from the center of the group. It is the 
time that the group center is at the route starting 
point that is given as the event time. 



I 1 

i TABLE 4-3 i 

I i 

1 ACTUAL START TIME FOR STRIKE ROUTES | 

I (excerpted from WGOUT) | 



TIME 1.046 BLUE STKl GRUP 2 MSSN EVNT 0 

BLUE GRUP XPOS 600.00 YPOS 180.00 
VELX 8.00 VELY -479. 93 

TIME 1.099 BLUE STK2 GRUP 3 MSSN EVNT 0 

BLUE GRUP XPOS 600.00 YPOS 180.00 
VELX 8.00 VELY -479.93 



The level of game time resolution in conjunction with 
the effects of truncation and precision on the algorithms 
involved in these processes could also possibly contribute 
to this difference. 
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Calculating the time for arriving at the first turn 
point, located at (10.00, 6.00) on the grid, gives the 
values shown in Table 4-4. 

Comparison of Table 4-4 against actual results given in 
Table 4-5 shows the same amount of difference in time at the 
first turn point as seen in the route entry time 
calculations, the initial difference just being carried 
along to this point. Calculated elapsed time is the same as 
the actual elapsed time for this leg of the route. 



TABLE 4-4 

EXPECTED GAME TIME AT FIRST TURN POINT 



Predicted time for entering the strike routes: 
Strike Group 1 at time 1.06 Hours 
Strike Group 2 at time 1.11 Hours 
Distance to first turn point = 180 NM 
Mission speed = 480 NM/Hour 
Elapsed time to first turn point: 

180 NM / 480 NM/Hour = 0.375 Hour 
Game time at first turn point for: 

Strike Group 1 = 1.064 + 0.375 = 1.439 Hours 
Strike Group 2 = 1.114 + 0.375 = 1.489 Hours 
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I 



TABLE 4-5 



ACTUAL GAME TIME AT FIRST TURN POINT 
(excerpted from WGOUT) 



I 

s 



TIME 1.421 BLUE STKl GRUP 2 MSSN EVNT 0 

BLUE GRUP XPOS 597.00 YPOS 360.00 
VELX -8.00 VELY 479.93 

TIME 1.474 BLUE STK2 GRUP 3 MSSN EVNT 0 

BLUE GRUP XPOS 597.00 YPOS 360.00 
VELX -8.00 VELY 479.93 



At the first turn point, Strike Group 1 takes a 45 
degree turn to the right, after which Strike Group 2 takes a 
45 degree turn to the left. The strike groups proceed to 
their second turn points, located at (13.00, 9.00) and 
(7.00, 9.00) on the grid respectively, which are equidistant 
from the first turn point. For this leg, calculation of the 
times in Table 4-6 will use the actual times at the previous 
route point, from Table 4-5 as the start time. A comparison 
of ■ only the calculated and actual elapsed times will be 
made . 

Comparison of the calculated results in Table 4-6 with 
the actual times in Table 4-7 reveals that elapsed time for 
Strike Group 1 was 0.009 hours less than calculated while 
that for Strike Group 2 was 0.003 hours more than 
calculated . 
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TABLE 4-6 



EXPECTED GAME TIME AT SECOND TURN POINT 



Distance to Second Turn Point = 254.558 NM 
Mission Speed = 480 NM/Hour 
Elapsed Time = 254.558 NM / 480 NM/Hour = 0.530 Hour 
Actual Game Time at First Turn Point for: 
Strike Group 1 = 1.421 Hours 
Strike Group 2 = 1.474 Hours 
Predicted Time at Turn Point 2 for: 

Strike Group 1 = 1.421 + 0.530 = 1.951 Hours 
Strike Group 2 = 1.474 + 0.530 = 2.004 Hours 



TABLE 4-7 

ACTUAL GAME TIME AT SECOND TURN POINT 
(Excerpted from WGOUT) 

TIME 1.942 BLUE STKl GRUP 2 MSSN EVNT 
BLUE GRUP XPOS 771.00 YPOS 540.00 
VELX 333.61 VELY 345.12 

TIME 2.007 BLUE STK2 GRUP 3 MSSN EVNT 
BLUE GRUP XPOS 415.00 YPOS 540.00 
VELX -341.28 VELY 337.53 






Another observat 
variation, is that 
getting larger with 



ion , 
the 
each 



which may be related to the time 
longitudinal position error is 
successive increment of travel. In 
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comparing the XPOS data from WGOUT in Table 4-5, with the 
route point position specified in the RTE category in 
SENSET , the XPOS 597.00 should be 600.00 to agree. The 
specified position, (10.00, 6.00), corresponds to WGOUT 
values of XPOS 600.00, YPOS 360.00 when the values from 
SENSET are multiplied by 60. 

Comparing the XPOS values from Table 4-7 with the 
specified route points from SENSET shows this positional 
error increasing. The increase is not uniform for the two 
different turn points, in spite of the fact that the route 
legs are. mirror images of each other. To be correct for the 
position specified in the RTE category of SENSET, the second 
turn point on Strike Route 1 should be at XPOS 780, YPOS 
540, corresponding to position (13.00, 9.00) in SENSET. As 
seen in Table 4-7, the XPOS is 771.00 which is 9.00 minutes 
of longitude or 9.00 NM less than the specified position. 
The second turn point for Strike Route 2 is shown to be XPOS 



415.00, YPOS 540.00 


in 


Table 4-7. 


In 


this 


case the XPOS 


should be 420.00 


to 


be correct 


f or 


the 


corresponding 


specified position 


in 


SENSET, which 


is 


(7.00 


, 9.00). The 



longitude of this turn point is also less than the specified 
position, by 5.00 minutes or 5 NM in this case. 

It appears that the program considers the position was 
reached when the center of each strike group reached YPOS 
540.00, executing the mission event for turning onto the 
next leg of the route. 
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At this point, Strike Group 1 takes a 45 degree turn to 
the left and Strike Group 2 takes a 45 degree turn to the 
right, proceeding on paths that converge on the Red Air 
Base, target for the strike. The next set of data to be 
examined is that concerning the detection and attack 
processes. Data from WGOUT is analyzed with respect to 
expected outcome based on capabilities assigned in DATBAS. 

The first detection of units of the Blue Strike forces 
occurs at game time 2.280 and at position XPOS 650.95, YPOS 
656.24 as shown in Table 4-8. Taking the position of the 
Red Base at XPOS 587.00, YPOS 720.00, from Table 4-8 the 
detection range is calculated by the rectangular coordinate 
method as shown in Table 4-9. 

Referring to the SRAD category of DATBAS in Table B-1 of 
Appendix B, the search radar type assigned to the Red Air 
Base is BG. Free space detection range of this radar is 
defined to be 150 NM, with 360 degree coverage. The search 
radar type assigned to the SAM Base is BH. Free space 
detection range of this radar is defined to be 70 NM, with 
360 degree coverage. 

It is of interest to note in Table 478 that both the Air 
Base and the SAM Base detected the BLUE FOll fighter group 
simultaneously. Although the detection range shown in Table 
4-9 is well within the 150 NM range of the Air Base radar, 
it is a good distance beyond the 70 NM range of the SAM Base 
radar. This can be explained by looking at the GRUP data 
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TABLE 4-8 



I 

RADAR DETECTION TIMES OF BLUE AIR | 

BY RED AIR BASE AND RED SAM BASE | 



I TIME 2.280 

1 RED BASE GRUP 199 GDET EVNT AGST BLUE FOll GRUP 6 

I RED GRUP XPOS 587.00 YPOS 720.00 

I VELX 0. VELY 0. 

1 BLUE GRUP XPOS 650.95 YPOS 656.24 
I VELX -343.12 VELY 335.66 

i TIME 2.280 

I RED BASA GRUP 200 GDET EVNT AGST BLUE FOll GRUP 6 

! RED GRUP XPOS 587.00 YPOS 720.00 

j VELX 0. VELY 0. 

I BLUE GRUP XPOS 650.95 YPOS 656.24 
I VELX -343.12 VELY 335.66 



TABLE 4-9 j 

DETECTION RANGE OF RED BASE AGAINST BLUE AIR I 

a 

I 

V((Red XPOS-Blue XP0S)2 + (Red YPOS-Blue YP0S)2) = I 

ft 

-V( (587. 00-650.95)2 + (720.00-656.24)2 ) = 90.305 NM 



: : r: 7 . 1 1 



category in DATBAS, where the SAM Base is defined as being 
collocated- with the Air Base. Referring to the Collocated 
Base definition in the CLM User’s Guide, Appendix A, the 
fact that collocated bases will be attacked as a single 
target and will respond as a single defensive force is 
explained . 
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The fact that the Air Base did not detect the incoming 
Blue Air group at the maximum range of 150 NM may be due to 
the strike route profile. Looking at the RTE category of 
SENSET, the third column contains the altitudes for the 
route legs. It can be seen that the altitude for the final 
inbound leg to the target for routes 1 and 2 is decreasing 
to 5000 feet. This could possibly prevent detection by 
keeping the Blue Air groups below the radar horizon for the 
Red Air Base. Table 4-10 shows the effect of the curvature 
of the earth on detection range of the Red Air Base at an 
altitude of 0 feet against the Blue Air groups at an 
altitude of 5000 feet. 



I 



I TABLE 4-10 

I 

j EARTH CURVATURE CONSTRAINED RADAR DETECTION RANGE 




1.229 * + -n/5000) = 86.903 NM 




While there is a small amount of variation, . 3.4 NM, 
between the results expected from Table 4-10 and the actual 
detection range from WGOUT, it appears that compensation for 
earth curvature is applied in the detection process. 

Once the incoming Blue Air Group was detected by the Red 
Air Base, the defensive response was initiated immediately 
by the collocated SAM Base, as shown by Table 4-11. Each 
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attack (ATTK) and corresponding terminate attack (TMAK) 
event pair, appearing to occur at the same time, represent 
the launching of a single surface-to-air missile (SAM) 
against the Blue Air group that has just been detected. 

Further study of the WGOUT file reveals that all 20 of 
the SAMs assigned to the Red SAM Base were utilized in the 
defensive response to the first 20 incoming Blue Air groups 
detected. Once the SAMs were expended, the defensive 
response shifted to the Red Air Base, which began launching 
its 12 sections of defensive air fighters. Although the Red 
Air groups began attacking the Blue Air groups, there was no 
apparent defensive response by the Blue defensive air 
fighters to counter-attack the Red fighters. 

Attack aircraft of the Blue Strike Groups 1 and 2 
carried out their mission, at tacking the Red Base, after 
which the Blue Strike Groups retired by way of the 
designated egress routes, back to the Blue Carrier. 
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TABLE 4-11 

DEFENSIVE RESPONSE OF RED SAM BASE 



I TIME 2.281 I 
I RED BASA GRUP 200 ATTK EVNT AGST BLUE FOll GRUP 6 i 
I RED GRUP XPOS 587.00 YPOS 720.00 I 
1 VELX 0. VELY 0. I 
I BLUE GRUP XPOS 650.60 YPOS 656.58 • I 
I VELX -343.12 VELY 335.66 ' 1 
i • I 
i TIME 2.281 1 
I RED BASA GRUP 200 TMAK EVNT AGST BLUE FOll GRUP 6 | 
I RED GRUP XPOS 587.00 YPOS 720.00 I 
I VELX ■ 0. VELY 0. I 
i BLUE GRUP XPOS 650.60 YPOS 656.58 I 
I VELX -343.12 VELY 335.66 i 
1 

3 ^ S 
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V. ISSUES OF VALIDATION AND VERIFICATION 



The data presentation of the preceding chapter is 
intended to serve as an illustration for the approach to be 
used in the process of validation and verification of the 
CLM. While exhaustive testing of this model would be an 
enormous task, beyond the scope of this thesis, the basic 
methods employed in evaluation of the data may be 
successfully employed in incremental efforts to test the 
correctness of the many different functions of the CLM. 

Initial efforts in the process should be geared toward 
the validation of the individual functions of the CLM. To 
accomplish this, simple scenarios should be designed to 
facilitate testing specific functions in an uncluttered 
environment. Other factors that recommend this approach are 
the lengthy running time of the model when large data sets 
are used and the massive size of the file WGOUT when large 
data sets and complex scenarios are employed. Using small 
data sets and simple scenarios results in shorter turnaround 
times and facilitates evaluation of data in a smaller output 
data set. 

When the basic functions of the CLM have been tested 
individually, larger, more complex scenarios should be 
constructed by combining the tested functional components of 
the original simple scenarios. This will allow the stepwise 
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investigation of any influences the functions may have on 
each other. 

Since the CLM is such a complex model it is probably 
infeasible to test all possible decision-decision paths that 
can be generated by a large scenario. There will be a level 
of complexity reached at some point in the validation and 
verification process where the diminishing returns gained by 
detailed evaluation of scenarios of any greater degree of 
complexity will not justify the effort required. 

In retrospect, the scenario evaluated in the previous 
chapter was too complex for a first level evaluation of CLM 
functions. With the complex actions of multiple groups 
involved in the air strike scenario, it is difficult to 
isolate on a single function and be sure that it is free of 
interference from the surrounding environment. As ijoted in 
the evaluation of scenario data, it is not certain whether 
the variation observed between the expect-ed and actual 
positions of the Blue Strike groups was a result of the way 
the program handles supergroups, or some other interaction. 
Likewise, it was not clear exactly what effect the 

collocation of the Red SAM Base with the Red Air Base had on 
the radar detection range observed. 

Specific functional areas to be assessed in the 
validation and verification process are kinematics, 
detection, response, attrition, and communication. This 
effort should include the evaluation of each of these 
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functional areas for sensitivity to error propagation in 
other functions. 

A. KINEMATICS 

The kinematic function involves the movement of force 
groups from one position to another according to mission 
directives or mission macro instructions contained in 
SENSET. Components of this function are original position, 
distance, speed, time, and new position. Errors propagated 
in this function will have an impact on detection and 
communication functions. If a group or unit is placed at a 
destination with a positional error, radar and/or sonar 
detection range may not produce the results intended by the 
scenario design. This will also have an impact on the 
interplay between communication signal strength, jamming, 
message reception and network performance. The degree of 
impact depends upon the magnitude of the error and how it 
propagates during the execution of the program. 

B. DETECTION 

The detection function involves determination of when a 
force group or unit falls within the detection parameters of 
a sensor of another force group or unit. Components of this 
function are sensor platform position, sensor range, sector 
coverage, sensor platform orientation, masking, altitude of 
both sensor platform and target, and target position. Any 
error propagated in this function will have an effect on 
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response time for defensive reaction by the sensor platform 
and also any actions to be initiated by other force units 
based on messages generated in response to the detection. 

C. RESPONSE 

The response function involves the automatic initiation 
of defensive measures against groups or units of a 
designated enemy force. Response occurs whenever an enemy 
force is detected by sensors or initiates an attack. The 



defensive 


response involves 


the 


utilization 


of 


whatever 


defensive 


weapon capabilities 


are 


assigned to 


the 


unit or 


group responding, such as 


point 


defense , 


SAMs 


or the 



launching of fighters. An example of a complex response 
would be the detection of inbound enemy aircraft by a remote 
surveillance aircraft or ship, generating a message to an 
aircraft carrier, which launches fighters to counter the 
threat. Errors propagated in any of the functions involving 
the force units in this detection-relay-response loop could 
alter the expected outcome in unpredictable ways. 

D. ATTRITION 

The attrition function involves the removal of units 
that are tagged as killed in action from any further 
participation in scenario events. Components of this 
function are the probability of kill (Pk) tables for weapon 
versus platform and platform versus platform in the WTBL and 
PTBL categories of DATBAS, respectively, and the 
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survivability per engagement probabilities in the MISW 
category of SENSET. Any errors propagated in the' 
interaction between Pk and survivability could result in 
unexpected outcome from engagements between enemy force 
groups . 

E. COMMUNICATION 

The communication function is the centerpiece of the 
CLM. All other functions provide the means by which events 
and action states are simulated to generate the 
communications load. Components of this function are 
communication doctrine, message types, sending units, 
receiving units, relay units, signal strength, jamming, and 
network capacity. The Communication System Model, still 
under development, is to perform the communication function 
of the CLM. The Communication System Model is designed to 
provide the capability to evaluate the performance of many 
different types of tactical communication networks. Once 
this module is interfaced to the CLM, its functions will 
need to be validated for correct response to the action 
state inputs from the wargame functions of the CLM. 

The processes of validation and verification of the CLM 
will involve making decisions on the level of error 
propagation to be tolerated. The criteria for these 
decisions should ultimately be based on the effect of any 
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errors on the communication functions critical to the proper 
evaluation of network performance. 

An important aspect to the validation and verification 
process is the proper design of scenarios for testing the 
functions. Close attention to detail is required in 
construction of the input data files DATBAS and SENSET. 
Good documentation is necessary to facilitate the 
translation of a scenario plan into correct user input data. 
The CLM User’s Guide is included as part of this thesis to 
provide documentation support for the validation and 
verification effort on the CLM. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



The primary objective of this thesis has been to 
investigate the structure and function of the CLM for the 
purpose of identifying an appropriate methodology for 
validation and verification. Utilizing the methods 
demonstrated in this thesis should facilitate the validation 
and verification effort. Since it is a large and complex 
model, the process of validating and verifying the CLM and 
its component functions will be very intensive and time 
consuming. Assigning teams to carry out the testing of the 
separate functions should be considered as a reasonable 
approach to this problem. 

The CLM shows excellent potential for development as a 
tool to evaluate communications network performance. 
Although originally intended to support JTIDS system 
development, changes to the CLM are providing the 
flexibility required to analyze the performance of a variety 
of communication network systems. Addition of the 
Communication System Model as a postprocessing module will 
be a major enhancement to the CLM, allowing complete user 
specification of communication system parameters. 

Development of scenario data sets during the research 
phase of this thesis effort was hampered by lack of coherent 
documentation. Solving problems in format and content of 
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the user input data files required searching through 
existing documentation that lacked indexing, page numbers, 
and made references to supporting data that did not exist. 
The existing documentation has also been rendered largely 
obsolete by the many changes already made to the CLM. This 
was the main influence for creating the user’s guide 
included in this thesis. It is recommended that a new set 
of documentation be created for the CLM and maintained to 
reflect changes made during the ongoing development efforts. 

With the ability to support joint service operation 
scenarios, the CLM exhibits good potential as a joint C^ 
training and analysis tool. As such, the CLM would be a 
valuable addition to the C^ academic program at the Naval 
Postgraduate School. With renewed DOD emphasis on joint 
service operations, the CLM can provide an excellent 
opportunity to build an experience base through joint 
service team studies at NPS. In order to facilitate hosting 
the CLM in the WAR Laboratory at NPS it is recommended that 
a study be undertaken to evaluate the nature of changes 
required to host the CLM. Changes to be considered should 
include both those involving the WAR Laboratory facilities 
and those involving the CLM itself. 

One change that would greatly enhance the portability 
and maintainability of the CLM would be the translation of 
the programs into a structured language such as Pascal, Ada, 
or C. A structured analysis and design of the CLM for such 
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a translation would provide an excellent opportunity for 
thesis study support at NPS . 

Use of this thesis is recommended for anyone desiring to 
become familiar with the CLM. It is also recommended as a 
reference for construction of the input data sets, DATBAS 
and SENSET, in preparing scenarios either for validation and 
verification work or for further studies of the model and 
its potential applications. 
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APPENDIX A 



CLM USER*S GUIDE 

The information contained in this section is a synthesis 
of material drawn from the Communication Load Model (CLM) 
Computer Program Development Specification [Ref. 1], the 
User’s Manual for the Communications Load Model (CLM) [Ref. 
2], operational experience with the CLM, and discussions 
with personnel at the Naval Air Development Center C^ Lab 
involved in the CLM project. This guide is intended for use 
by personnel who have a basic understanding of what the CLM 
is and how it functions. While intimate familiarity with 
the CLM is not a requirement for successful use, it is 
assumed that the user has a clear idea of the problem to 
which the CLM is applied. To this end it is recommended 
that the user prepare a "Game Plan" before approaching the 
scenario construction process. A list of the types of 
forces and units to be involved and their capabilities 
should be compiled first. This list may then be translated 
into the required formats for DATBAS. The most useful 
planning aid for SENSET is a sheet of graph paper. Laying 
out the "playing field", a grid with 20 degrees of longitude 
and 15 degrees of latitude facilitates the placement and 
disposition of forces. Once the game latitudes and 
longitudes are assigned to the grid, it is much easier to 
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visually plan routes for Mission Macros and Mission 
Directives. This avoids a lot of tedious calculations for 
the required data entries. The purpose of this guide is 
simply to enable the user to effectively understand and 
utilize all of the features and functions of the CLM. 

A. USER INPUT 

User input to the CLM is by way of the files DATBAS and 
SENSET. DATBAS is, simply, a data base in which all the 
basic tactical units and their operational parameters are 
defined. The composition of groups and supergroups made up 
of these units is also defined in DATBAS. SENSET provides 
the data that drive the scenario by defining actions, in 
Mission Macros and Mission Directives to be executed by the 
supergroups, groups and units . involved in the scenario. 

1 . DATBAS 

This is the file in which data descriptions and 
formats for force structure are entered. There are 21 
categories of data that may be entered in DATBAS. Data are 
entered in 80 column card format, with each line in a 
category corresponding to a single "card". Each category 
begins with a header card that contains only the category 
name of 2, 3, 4, or 5 characters. The card format is only a 
logical view imposed on the data file, as cards are not 
actually used. A list of the categories by name, with a 
short explanation of each is presented here. 
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Category 
UNIT - 
JTIDS - 
SHAD - 
EW 

SSON - 
LSON - 
WPN 

JAMM - 
STGT - 
WTGT - 
PTGT - 
DTBL - 
WTBL - 
PTBL - 
LTBL - 
GASP - 
SGRP - 
GRUP - 
MSGA - 
COI 

MSGL - 



Description 

Force unit types and capabilities 
Communication equipment types 
Search radar types 

Electronic warfare equipment types 
Search sonar types 
Localization sonar types 
Weapon types 

Hostile jammer equipment 

Sonar target table 

Weapon target table 

Platform target table 

Sonar detection range table 

Weapon kill probability table 

Platform kill probability table 

Platform vs platform kill rate table 

Close air support patterns 

Super group composition 

Regular group composition 

Message types 

Communication communities of interest 
Communication doctrine 



Two categories which must always have data entered 



are UNIT and GRUP. The reason for this is that the smallest 
entity recognized for assignment of mission directives or 
mission macros is the regular group, even if it consists of 
only a single unit. 

In addition to the format and domain constraints 



within each category, there are also constraints involving 
data relationships between the categories. These will be 
pointed out in the descriptions of the categories and must 
be carefully observed whenever entries are made in DATBAS. 
There are also constraints involving relationships between 
data in DATBAS and declarations made in SENSET that will be 



noted in this section and also in the section pertaining to 
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